home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1682 < prev    next >
Text File  |  1995-07-25  |  22KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Bound
  8. Request for Comments: 1682                 Digital Equipment Corporation
  9. Category: Informational                                      August 1994
  10.  
  11.  
  12.                  IPng BSD Host Implementation Analysis
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the big-internet@munnari.oz.au mailing list.
  26.  
  27. Overview
  28.  
  29.    This IPng white paper, IPng BSD Host Implementation Analysis,
  30.    was submitted to the IPng Directorate to provide a BSD host point of
  31.    reference to assist with the engineering considerations during the
  32.    IETF process to select an IPng proposal.  The University of
  33.    California Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4)
  34.    system implementation on a host is used as a point of reference for
  35.    the paper.
  36.  
  37.    This document only reflects the author's personal analysis based on
  38.    research and implementation experience for IPng, and does not
  39.    represent any product or future product from any host vendor.  Nor
  40.    should it be construed that it is promoting any specific IPng at this
  41.    time.
  42.  
  43. Acknowledgments
  44.  
  45.    The author would like to acknowledge the many host implementation
  46.    discussions and inherent knowledge gained from discussions with the
  47.    following persons within Digital over the past year: Peter Grehan,
  48.    Eric Rosen, Dave Oran, Jeff Mogul, Bill Duane, Tony Lauck, Bill Hawe,
  49.    Jesse Walker, John Dustin, Alex Conta, and Fred Glover.  The author
  50.    would also like to acknowledge like discussions from outside his
  51.    company with Bob Hinden (SUN), Bob Gilligan (SUN), Dave Crocker
  52.    (SGI), Dave Piscitello (Core Competence), Tracy Mallory (3Comm), Rob
  53.    Ullmann (Lotus), Greg Minshall (Novell), J Allard (Microsoft), Ramesh
  54.    Govinden (Bellcore), Sue Thompson (Bellcore), John Curran (NEARnet),
  55.  
  56.  
  57.  
  58. Bound                                                           [Page 1]
  59.  
  60. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  61.  
  62.  
  63.    Christian Huitema (INRIA), and Werner Volgels (INESC).  The author
  64.    would also like to thank Digital Equipment Corporation for the
  65.    opportunity to work on IPng within the IETF as part of his job.
  66.  
  67. 1. Introduction
  68.  
  69.    A host in the context of this white paper is a system that contains
  70.    an operating system supporting a network subsystem as one of its
  71.    parts, and an interprocess communications facility to access that
  72.    network subsystem.  These hosts are often referenced as a
  73.    Workstation, Server, PC, Super Computer, Mainframe, or an Embedded
  74.    System (Realtime Devices).
  75.  
  76.    IPng will require changes to a hosts network software architecture.
  77.    Those changes should be as transparent as possible to the existing
  78.    IPv4 applications executing on hosts.
  79.  
  80.    After discussing the network software architecture for a BSD host the
  81.    paper will discuss the perceived network software alterations,
  82.    extended capabilities, transition software, and a deployment
  83.    consideration for IPng hosts.
  84.  
  85.    The inclusive OR of all IPng proposals was used to develop the
  86.    engineering considerations discussed in this paper.
  87.  
  88. 2. Network Software Architecture
  89.  
  90.    The BSD host network software architecture consists essentially of
  91.    three components: the interprocess communications facility, the
  92.    network communications subsystem, and the network protocols
  93.    supported. These three components are tightly coupled and must be
  94.    integrated in a way that affords high performance for the
  95.    applications that are dependent on these components to interoperate
  96.    efficiently.  A BSD host implementation view of the TCP/IP protocol
  97.    suite is depicted in the following network architecture diagram.
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Bound                                                           [Page 2]
  115.  
  116. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  117.  
  118.  
  119.    +-----------------------------------------------------------------+
  120.    |                        Application Layer                        |
  121.    |                                                                 |
  122.    |                Socket and Network Library APIs                  |
  123.    |                                                                 |
  124.    |  BIND DNS                                                       |
  125.    |  SNMP Management                                                |
  126.    |                          User Space                             |
  127.    +-----------------------------------------------------------------+
  128.    |                         Kernel Space          AF_INET           |
  129.    |                                        Communications Domain    |
  130.    |  Socket Layer                                                   |
  131.    |                                                                 |
  132.    |                     Transport Layer TCP & UDP                   |
  133.    |                                               Queues/Control    |
  134.    |                                                 Blocks          |
  135.    |                        Network Layer                            |
  136.    |              +-----------------------------------+              |
  137.    |              | IPv4 Modules  Discovery Multicast |              |
  138.    |              |                ICMP       IGMP    |              |
  139.    |              |                   Routing         |   Routing    |
  140.    |              |                RIP        EGP     |   Tables     |
  141.    |              |                OSPF       BGP     |              |
  142.    |              |                I-IS-IS    IDRP    |              |
  143.    |              +-----------------------------------+              |
  144.    |                     Link Dependent Layer                        |
  145.    |              +-----------------------------------+              |
  146.    |              | ARP, RARP, InARP, NCPs, Addr Tbls |              |
  147.    |              +-----------------------------------+              |
  148.    |  Discovery & Interface                                          |
  149.    |      Cache                                                      |
  150.    |                     Data Link Layer                             |
  151.    |              +-----------------------------------+              |
  152.    |              | Ethernet, FDDI, ATM, HIPPI, PPP   |              |
  153.    |              +-----------------------------------+              |
  154.    +-----------------------------------------------------------------+
  155.  
  156. 2.1 Interprocess Communications Facility
  157.  
  158.    The interprocess communications (IPC) facilities includes three
  159.    critical parts:
  160.  
  161.       1.  The IPC mechanism to the network communications subsystem.
  162.       2.  The ability to access a network protocol set within that
  163.           subsystem.
  164.       3.  The structures supporting the network communications
  165.           subsystem.
  166.  
  167.  
  168.  
  169.  
  170. Bound                                                           [Page 3]
  171.  
  172. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  173.  
  174.  
  175.    The IPC facility has two implementation parts.  The part in user
  176.    space and the part in kernel space within the operating system. This
  177.    is often not differentiated and why in the previous network
  178.    architecture diagram you will see sockets in both user and kernel
  179.    space.  An IPC supports in user space an application program
  180.    interface (API) which application developers use to access the
  181.    network communications features of the host. These APIs have
  182.    corresponding functions in the kernel space which execute the
  183.    functions requested by the user space requests through the APIs.
  184.  
  185.    The sockets paradigm on a BSD host defines the data structure of the
  186.    network address within a selected protocol family (communications
  187.    domain) in the network subsystem.  This data structure consists of an
  188.    address family, a port for the protocol selected, and a network
  189.    address.
  190.  
  191.    The IPC facility on a host is dependent upon its interface to the
  192.    BIND DNS application which is the defacto method when using TCP/IP to
  193.    retrieve network addresses.
  194.  
  195.    Other interfaces that may be required by applications to properly set
  196.    up the network connection within the IPC facility include:
  197.    setting/getting options for the protocols used, obtaining/accessing
  198.    information about networks, protocols, and network services, and
  199.    sending/transmitting datagrams.
  200.  
  201. 2.2 Network Communications Subsystem
  202.  
  203.    The network communications subsystem consists of the following
  204.    generic parts as depicted in the previous network architecture
  205.    diagram: transport layer, network layer, link dependent layer, and
  206.    data link layer.  These may not be implemented as true distinct
  207.    layers on a BSD host, but they are referenced in this white paper in
  208.    that manner for purposes of discussion.
  209.  
  210.    The transport layer supports the application interface into the
  211.    network communications subsystem and sets up the parametric pieces to
  212.    initiate and accept connections.  The transport layer performs these
  213.    functions through requests to the lower layers of the network
  214.    communications subsystem.  The transport layer also supports the
  215.    queues and protocol control blocks for specific network connections.
  216.  
  217.    The network layer supports the modules to build and extend the
  218.    network layer datagram, the control protocol datagrams, and the
  219.    routing abstraction on the host.  This layer of the network
  220.    communications subsystem on a BSD host is often extended to provide
  221.    both interior and exterior routing functionality.
  222.  
  223.  
  224.  
  225.  
  226. Bound                                                           [Page 4]
  227.  
  228. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  229.  
  230.  
  231.    The link dependent layer supports the modules that provide an
  232.    interface for the network communications subsystem to map network
  233.    addresses to physical addresses, and build the necessary cache so
  234.    this information is available to the host network software.
  235.  
  236.    On a BSD host the network layer and link dependent layer together
  237.    provide system discovery for hosts and routers.
  238.  
  239.    The data link layer supports the modules that define the structures
  240.    for communicating with the hardware media used by the host on the
  241.    local network.
  242.  
  243. 2.3 Network Protocols
  244.  
  245.    The TCP/IP protocol suite as defined by the IETF RFC specifications
  246.    are the set of network protocols used by this white paper for
  247.    reference.
  248.  
  249. 3. Network Software Alterations
  250.  
  251.    The IPng network software alterations to a BSD host perceived at this
  252.    time are as follows:
  253.  
  254.       1.  Applications Embedding IPv4 Addresses.
  255.       2.  Transport Interfaces and Network APIs.
  256.       3.  Socket Layer and Structures.
  257.       4.  Transport Layer.
  258.       5.  Network Layer Components.
  259.       6.  Link dependent Layer.
  260.  
  261. 3.1 Applications Embedding IPv4 Addresses
  262.  
  263.    Internet style applications in this white paper are the set of
  264.    protocols defined for an end user using TCP/IP to exchange messages,
  265.    transfer files, and establish remote login sessions.
  266.  
  267.    Applications use the sockets network APIs to maintain an opaque view
  268.    of the network addresses used to support connections across a
  269.    network. Opaque in this context means that the application determines
  270.    the network address for the connection and then binds that address to
  271.    a socket.  The application then uses the reference defined for that
  272.    socket to receive and transmit data across a network.
  273.  
  274.    An application that embeds an IPv4 network address within its
  275.    datagram has made an underlying assumption that the format of that
  276.    address is permanent.  This will cause a great problem when IPng
  277.    causes addresses to change.  Thus far only one Internet style
  278.    application has been determined to cause this problem and that is FTP
  279.  
  280.  
  281.  
  282. Bound                                                           [Page 5]
  283.  
  284. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  285.  
  286.  
  287.    [1,2].
  288.  
  289. 3.2 Transport Interfaces and Network APIs
  290.  
  291.    The transport interface and network API enhancements that must take
  292.    place on a BSD host because of IPng are alterations that affect the
  293.    size of the network address used by the socket data structure.
  294.    Depending on how this is implemented on the host, supporting both
  295.    IPv4 and IPng could require existing IPv4 applications to be
  296.    recompiled.  In the worst case it could require modifications to the
  297.    existing IPv4 applications software that accesses the network
  298.    communications subsystem.
  299.  
  300.    There will have to be enhancements to the network APIs that an
  301.    application uses to retrieve BIND DNS records to differentiate
  302.    between IPv4 and IPng address requests.
  303.  
  304.    The network API enhancements and how they are implemented will affect
  305.    the capability of any IPng proposal on a BSD host to be able to
  306.    interoperate between an IPv4 only, an IPng only, and an IPng-IPv4
  307.    host system.
  308.  
  309.    Depending on the IPng proposal selected the network options,
  310.    services, and management objects will have to be extended at the
  311.    transport interface so those features can be accessed by applications
  312.    software.
  313.  
  314. 3.3 Socket Layer and Structures
  315.  
  316.    The socket layer and structures will require changes to support any
  317.    IPng proposals network address.  In addition new or removed options
  318.    and services will need to be incorporated into the socket abstraction
  319.    within the network communications subsystem.
  320.  
  321. 3.4 Transport Layer
  322.  
  323.    The transport layer will need to be modified to support any new or
  324.    removed services proposed by an IPng solution set.  The transport
  325.    layer will become more overloaded to support the binding of either
  326.    the IPv4 or IPng network layer components to differentiate the
  327.    services and structures available to a host application.  The
  328.    overload will also take place to support functionality removed in the
  329.    network layer and moved to the transport layer if proposed by an IPng
  330.    solution.
  331.  
  332.    It will also take some design thought to implement IPng so the
  333.    hundreds of man years invested in performance improvements in the
  334.    host transport layer are maintained.   This must be analyzed in depth
  335.  
  336.  
  337.  
  338. Bound                                                           [Page 6]
  339.  
  340. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  341.  
  342.  
  343.    and should be part of the operational testing of any IPng proposal.
  344.  
  345. 3.5 Network Layer Components
  346.  
  347.    The network layer components for IPng will require the greatest
  348.    alterations on a host.  In addition a host will be required to
  349.    maintain an integrated network layer below the transport layer
  350.    software to support either the IPng or IPv4 network layer and
  351.    associated components.
  352.  
  353.    Depending on the IPng selected the host alterations to the network
  354.    layer components will range from complete replacement with new
  355.    protocols to extensions to existing IPv4 network layer protocols to
  356.    support IPng.
  357.  
  358.    All IPng proposals will affect the BSD host routing abstraction to
  359.    maintain host software that supports interior and exterior routing.
  360.    Depending on the proposal selected those changes can cause either a
  361.    complete new paradigm or an update to the existing IPv4 paradigm.
  362.  
  363.    System discovery of nodes on the local subnetwork or across an
  364.    internetwork path in all IPng proposals will require changes to the
  365.    BSD host software network layer component.
  366.  
  367. 3.6 Link dependent Layer
  368.  
  369.    The link dependent layer on a host will need to accommodate new IPng
  370.    addresses and the system discovery models of any IPng proposal.
  371.  
  372. 4. Extended Capabilities with IPng
  373.  
  374.    Extended capabilities that could be implemented by BSD hosts are
  375.    listed below.  Many of these capabilities exist today with IPv4, but
  376.    may require changes with the implementation of IPng.  Some of them
  377.    will be new capabilities.
  378.  
  379. 4.1 Autoconfiguration and Autoregistration
  380.  
  381.    Today hosts can provide autoconfiguration with DHCP using IPv4
  382.    addresses. IPng hosts will be faced with having to provide support
  383.    for existing IPv4 addresses and the new IPng addresses.  In addition
  384.    the boot-strap protocol BOOTP used to boot minimal BSD host
  385.    configurations (e.g., diskless nodes) will need to be supported by
  386.    IPng hosts.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Bound                                                           [Page 7]
  395.  
  396. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  397.  
  398.  
  399. 4.2 PATH MTU Discovery
  400.  
  401.    PATH MTU discovery appears to be something each proposal is
  402.    considering.  Alterations to the existing implementation of PATH MTU
  403.    are perceived because changes are expected in system discovery.
  404.  
  405. 4.3 Multicast
  406.  
  407.    Each proposal has depicted alterations to Multicast that will affect
  408.    present BSD host implementations of IPv4 Multicast.  In addition it
  409.    appears that the IPv4 unicast broadcast will be replaced by a
  410.    multicast broadcast.
  411.  
  412. 4.4 Flow Specification and Handling
  413.  
  414.    This will be an extended capability proposed by all IPngs'.
  415.  
  416. 4.5 System Discovery
  417.  
  418.    Each proposal has depicted a new model for IPng system discovery of a
  419.    host.
  420.  
  421. 4.6 Translation and Encapsulation
  422.  
  423.    The routing abstraction in a BSD host will have to deal with the
  424.    affect of any translation or encapsulation of network layer
  425.    datagrams, if they are required by an IPng.
  426.  
  427. 4.7 Network Layer Security
  428.  
  429.    It is perceived that network layer security will be required at the
  430.    network layer component of IPng and this will have to be implemented
  431.    by a BSD host.
  432.  
  433. 4.8 Socket Address Structure
  434.  
  435.    The network kernel socket address structure will change because of
  436.    IPng.
  437.  
  438. 4.9 Network APIs
  439.  
  440.    The network APIs for a BSD host will have to be enhanced to support
  441.    IPng.  In addition any new options available to the applications
  442.    because of the IPng network service will have to be added as an
  443.    option to the APIs.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Bound                                                           [Page 8]
  451.  
  452. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  453.  
  454.  
  455. 4.10 Network Management
  456.  
  457.    Network management for IPng will have to support new network objects
  458.    as defined by the IPng proposal.  In addition the data structures in
  459.    the BSD host network kernel used as information to display network
  460.    topology will be altered by a new network layer datagram and
  461.    associated components.
  462.  
  463. 5. Transition Software
  464.  
  465.    Transition software in this white paper references the network
  466.    software alterations on a host to support both IPv4 and IPng for
  467.    applications and the hosts operating system network kernel.  It is
  468.    the subject of another set of papers to identify the transition
  469.    software required by network managers to transition their users from
  470.    IPv4 to IPng.
  471.  
  472.    Transition software on a host will be required to maintain
  473.    compatibility between IPv4 and IPng, and to manage both the existing
  474.    IPv4 and IPng environments as follows:
  475.  
  476.       1.  BIND DNS record updates and handling by the application.
  477.       2.  SNMP management interface and monitoring of host network
  478.           structures.
  479.       3.  APIs supporting IPv4 and IPng differentiation for the
  480.           application.
  481.       4.  Defacto network tools altered (e.g., tcpdump, traceroute,
  482.           netstat).
  483.       5.  ARP to new system discovery.
  484.       6.  BOOTP diskless node support for IPng.
  485.       7.  DHCP integration with IPng Autoconfiguration.
  486.       8.  Routing table configuration on the BSD host (e.g., routed,
  487.           ifconfig).
  488.       9.  Selection of the network layer (IPv4 or IPng) at the
  489.           transport layer.
  490.       10.  New options and services provided by an IPng protocol.
  491.       11.  IPv4 and IPng routing protocols in the network layer.
  492.       12.  IPv4 and IPng system discovery in the network layer.
  493.  
  494.    These are only the highlights of the transition software that a host
  495.    will have to deal with in its implementation of IPng.  The host
  496.    network architecture diagram depicted previously will require
  497.    software enhancements to each label in the diagram.
  498.  
  499.    It is very important that each IPng proposal provide a specification
  500.    for a transition plan from IPv4 to IPng and their technical criteria
  501.    for the interoperation between IPv4 and IPng.
  502.  
  503.  
  504.  
  505.  
  506. Bound                                                           [Page 9]
  507.  
  508. RFC 1682         IPng BSD Host Implementation Analysis       August 1994
  509.  
  510.  
  511.    It should also be a requirement that existing IPv4 applications not
  512.    have to be recompiled when a host has implemented both an IPv4 and an
  513.    IPng network layer and associated components.
  514.  
  515.    It is very desirable that when a host implements both an IPv4 and an
  516.    IPng network layer and associated components that there is no
  517.    performance degradation on the host compared to the performance of an
  518.    existing IPv4 only host.
  519.  
  520.    It should not be a requirement by IPng that a host must support both
  521.    an IPv4 and an IPng network layer.
  522.  
  523. 6. A Deployment Consideration
  524.  
  525.    Complete and extensive technical specifications must be available for
  526.    any IPng proposal, and a selection of any proposal must accommodate
  527.    multiple implementations. The IPng Directorate should review proposed
  528.    specifications for completeness.
  529.  
  530.    It is important that the IPng Directorate determine how long the CIDR
  531.    IPv4 address plan can extend the life of IPv4 addresses on the
  532.    Internet.  This variable can affect the time we have to deploy IPng
  533.    and the proposed transition plans.
  534.  
  535. References
  536.  
  537.    [1] Gilligan, B., et. al., "IPAE: The SIPP Interoperability and
  538.        Transition Mechanism", Work in Progress.
  539.  
  540.    [2] Piscitello, D., "FTP Operation Over Big Address Records
  541.        (FOOBAR)", RFC 1639, Core Competence, Inc., June 1994.
  542.  
  543. Security Considerations
  544.  
  545.    Security issues are discussed in Section 4.7.
  546.  
  547. Author's Address
  548.  
  549.    Jim Bound
  550.    Digital Equipment Corporation
  551.    110 Spitbrook Road ZK3-3/U14
  552.    Nashua, NH 03062-2698
  553.  
  554.    Phone: +1 603 881 0400
  555.    EMail: bound@zk3.dec.com
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Bound                                                          [Page 10]
  563.  
  564.